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(57) Abstract: The prcse&t invention enables a content provider to dynamically assembb content at the edge oftbe Internet, prefer- 
ably on conccot delivery netwoik (CDN) edge servers. Prefenbly, the content provider leverages an "edge side include" (ESI) mailcup 
language that is used to define Web page fragments for dynamic assembly at the edge. Dynamic assembly improves sitcperfonnance 
by cBiching the uKjecis that comprise dynamical^ generated pages at the edge of the Internet, close Il> the end user. The conlcnl 
provider designs and develops the business lugic co fomi and assemble the pages, for example, by using the ESI language within its 
development environment Instead of being assembled by an appUcalioii/wbb server in a centralised data center, (he applicatioiirweb 
server sends a pa^o umplata and oonicni fragnvents to a CDN Higo server where tho pago is assembled. Bach content fiagmaru can 
have its own cachesdiitily pmHle to manage the "tehncss" of the contem. Onoe a user i-oquesis a page (template), cite edge server 
examines its cache for the included fiagments and assembles 8ie page on*th&-ay. 
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Web-based applications that are accessible by customerSy suppliers and partners. The 
business processes that must come together to drive this new generation of online 
applications, however, are more complex than ever before. Far from the HTML and 
static pages of years past; the new breed of applications depends on hundreds, if not 
thousands of data sources. The content involved now feeds dynamic, personalized 
Web-based applications. 

Delivering personalized content however, is not new. Many Web destinations, 
mainly portal sites, use pCTsonalization to aeate a unique user «perience. The look 
and feel and content of such a site are determined by an individual's preferences, 
geographic location, gender, and the like. By nature, tfiese sites rely heavily on 
application servers and/ or content management systems and the use of well-known 
techniques (such as cookies) to create this dynamic and personalized user experience. 
The majority of pages on these sites, however, are considered non-cachcable and, as a 
consequence, content distribution of such pages from the edge of the Internet has not 
been practical. 

Consider the example of an online retailer for electroiuc products. When a user 
accesses the site and searches for, say, Hmdhelds, that request is sent to the application 
server. The application server performs a database query and assembles tiie page based 
on the return values and other common page components, such as navigation menu, 
logos and advertisement. The izser then receives die assembled page containing 
prodtict fanages, product descriptions, and advertiang. This is illustrated in Figure Z 
The next time the user (or anotiier user) access that page, the same steps need to 
happen, which introduces unnecessary latency in delivery of the content to the end 
user. On occasion, the page migjit be cached within the application server's tntemal 
cache, in which case the request would still have to be satisfied from the origin server, 
requiring a full round-trip from browser to origin server and back and requiring 
additional computational processes on the application server^ necessitating more CPU 
and memory usage. 

It would be highly desirable to be able to cache the dynamic page closer to 
requesting end users. As is well known, content delivery networks (CDNs) have the 
capability of caching frequentiy requested content doser to end users in servers located 
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near the "edge" of the Internet CDMs provide users with fast and reliable delivery of 
Web content streaming media, and software applications across the Internet Users 
requesting popular Web content may well have those requests served from a location 
much closer to them (e.g., a CDN content server located in a local network provider's 
5 data center), rather tiian torn much farther away at the original Web server. By serving 
content requests from a server much doser electronically to the user, a quality G^N can 
reduce the likelihood of overloaded Web servers and Internet delays. 

Returning back to the example, assume that the content provider assigned the 
dynamic page a Time To live (TTL) of one (1) day, for example, because there are only 

1 0 infrequent changes to the inventory for Handhelds, The first time a user requests the 
page it is assembled by the application server as described in Figure 2. Because the 
page has a TTL of one day, it would be highly desirable to be able to store the page on 
the CDN edge servers for that time period, so that all subsequent requests for ttiat page 
cotdd be served from a server closer to other requesting end users who might want 

15 similar information. This is illustrated in Figure 3* This cached version preferably 

would indude those product images and desciipdon that axe common components and 
generally do not vary from user to user. Even though the page was origiiudly 
assembled for an individual user, it would be desirable to be able to cadie given 
fragments themselves so that the building blocks of die page can be shared between 

20 users. 

The dynamic content assembly mechanism of the present invention provides this 
functionality. 

BRIEF SUMMARY OF THE INVENTION 

The invention provides die ability to dynamically assemble content at the edge of 
25 the Internet, e.g., on CDN edge servers. To provide this capability, preferably the 
content provider leverages a server side scripting language (or other server-based 
functionality) to define Web page fragments for dynamic assembly at the edge. 
Djmamic assembly can improve site perfonnance by caching the objects that comprise 
dynamically generated PiTML pages at the edge of the Internet, dose to the end user. 
30 ITie content provider designs and develops the business logic to form and Eissemble the 
pages, preferably using an "edge side include" (ESI) language v^thin its development 
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environment This business logic is then interpreted by the edge servers to produce a 
response for the end user. 

Instead of being assembled by an application/web server in a centralized data 
center^ the application/ web server sends a page container (or ''template") and content 
5 fragments to a CDN edge server where the page is assembled A ''content fragment' 
typically is some atomic piece of content in a larger piece of content (eg., die container) 
and that, preferably, has its own cacheability and refresh properties. Once a user 
requests a page, the edge server examines its cache for the included fragments and 
assembles the page maricup (e,g., HTML) on-the-fly. 1£ a fragment has expired or is not 

10 stored on the edge server, the server contacts the origin server or another edge server, 
preferably via an optimized connection/ to retrieve the new/ missing fragment The two 
main benefits of this process are faster loading pages, because pages are assembled 
closer to the end user, instead of on the origin server, and reduced traffic/ load on the 
application/web server^ because more requests can be satisfied on the network edge 

I S and smaller pieces of content are being transmitted between the origin server and edge 
server. The present Invention thus allows the content provider to separate content 
generation and/ or management, which may lake place in a centralized location^ from 
content assembly and delivery, which can take place at the edge of die Internet 
More generally, the dynamic content assembly mechaiusm of the present 

20 invention provides the base layer of a pluggable architecture from which one or more 
processing engines (e^g., tect such as HTML, XSLT, Java, PHP, and the like) may be 
instantiated and used to process a container and its content fragments. Thus, for 
example, a given request received at the edge server is mapped to a given base 
processor, preferably by content provider-specific metadata^ and one or more additional 

25 processors may then be instantiated to enable content fragments to be assembled into 
the container to create an assembled response tfiat is then sent back to the requesting 
end user. 

The foregoing has outlined some of the pertinent features and advantages of tlie 
present invention. A more complete understanding of tihe inventionis provided in the 
30 following Detailed Description of the Preferred Embodiment. 
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BRIEF DESCRHTION OF THE DRAWINGS 
Figure 1 illustrates a conventional e-business Web site having an application 
server and a content management system to assemble and deliver personalized content 
from a centralized location; 
5 Figure 2 illustrates how the application server in the Web site of Figure 1 

generates a d3mamic page in response to an end user request; 

Figure 3 illustrates how a dynamic page may be cached on a content delivery 
network (CDN) edge server according to a technical advantage of tiie present invention; 
Figure 4 illustrates a representative ''container" page having individual content 
1 0 fragments that may be assigned individual caching profiles and behaviors according to 
the present invention; 

Figure 5 illustrates a dynamic page that is assembled by the dynamic content 
assembly mechanism of the present invention; 

Figture 6 is representative markup for the page shown in Figure 5; 
15 Figure 7 is representative HTML returned from the origin server as a result of the 

edge server tunneling a request for non-cacheable content; 

Figure 6 is a representative edge serv^er that may be used to implement the 
dynamic content assembly mechanism; 

Figure 9 is a flowchart of HTML container page assembly according to the 
20 present invention; 

Figure 10 is a flowchart of XML container pagie assembly according to the 
present inventioa* 

Figure 11 illustrates how the dynamic content assembly mechanism of the 
present invention instantiates an associated processor to carry out an edge-based 
25 d3mamic content assembly function; and 

Figure 12 illustrates how the remote assembly and caching of a page and/or its 
fragments enables a content provider to reduce Web site infrastructure. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
The dynamic content assembly mechanism of the present invention leverages 
30 any servet side scripting language or other server-based functionality. In a preferred 
embodiment^ the functionality is a variant of server side include processing that is 
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sometimes referred to as an "edge side include'^ to emphasize that the processing is 
carried out on an edge server. Traditionally^ server side include languages use 
directives that are placed in HTML pages and that are evaluated on a ser\'er before the 
page is served. They provide a way to enable the server to add dynamically<^enerated 
S ccmtent to an existing HTML page. 

According to the invention^ ESI is a simple markup language used to define the 
business logic for how Web page components are dynamically assembled and delivered 
from the edge of the Internet More specifically, ESI provides a way for a content 
provider to express the business logic of how an ICDN should be assembling the 
10 content provider's pages. Thus, ESI is a common language that tiKe content provider 
can use and tihe CDN service provider can process for content assembly, aeation, 
management and modification. ESI provides a mechanism for assembling dynamic 
content transparendy across application server solutions, content management systems 
and content delivery networks. It enables a content provider to develop a Web 
1 5 application once and choose at deployment time where the application should be 
assembled, eg,, on a content management system, an application server, or the CDN, 
thus reducing complexity, development time and deployment costs. ESI is described in 
detail at http:/ / www.edge-delivery.org/sp6cJitmL ESI provides the content 
provider/ devdoper with ti\e following capabilities: 
20 » Inclusion ^ a central ESI feature is tfie ability to fetch and include files that 

comprise a web page, with eadi file preferably subject to its own configuration 
and control, namely, cacheability properties, refresh properties, and so forth. 
An <esi:include> tag or similar construct may be used for this purpose. An 
indude statement can have a time-to-live (ITL) attribute that specifies a time-1x)- 
25 live in cache for the included fragment 

t Environmental variables— ESI supports use of a subset of standard CGI 

environment variables such as cookie information* These variables can be used 
inside ESI statements or outside ESI blocks. An <esl:vars> tag or similar 
construct may be used for this purpose. 
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• Conditional inclusion - ESI supports conditional processing based on Boolean 
comparisons or environmental variables. An <esi:choose> tag or similar 
construct may be used for this purpose. 

• E^cception and error handling-]^ allows specification of alternative pages and 
5 for default behavior in the event that an origin site or document is not available. 

An <esi±ry> tag or similar construct may be used to specify such alternative 
processing, e.g, when a request fails. Further, it provides an explicit exception- 
haiidling statement set 

ESI provides a numb^ of features that make it easy to build highly dynamic 

10 Web pages: coexistence of cacheable and'non-cacheable content on the same page, 

separation of page assembly logic and delivery (so that complex logic required to select 
the content itself is separated* from tiie delivery of that content), the ability to perform 
ESI processing recursively on components themselves, and the ability to perform logic 
(e.g., certain personalization and conditional processing) on an edge server. The ESI 

1 5 language recognizes the fact that many pages have dynamic and often non-cacheable 
content. By breaking up Web pages into individual components, each with different 
cache policies, ESI makes it easy to speed up the delivery of dynamic pages. Only those 
components that are non-cacheable or need updating are requested from the origin 
server. This results in a considerable speed improvement over the prior art of 

20 centralized assembly and ddivery of dynamic content 

Recursive ESI logic may be used to separate page logic from content delivery. 
Any ESI fragment can, in tunv contain other fragments, etc.- In particular, a non- 
cacheable dynamic fragment can contain include functionality, e.g., an <esi:includes> 
tag set, to point to cacheable sul>-£ragmenis. Personalization is provided, e.g., using an 

25 <esi:choosG> tag, that allows content providers to include different content fragments 
based on: user-agent and other header values, cookie values, a user's location, a user's 
coimection speed, and the Uka Finally, many different variables (e.g., cookie-based 
variables^ query-string acceptJanguage, etc.) can be substituted into the text of the 
page, which makes many previously non-cacheable personalized pages easily 

30 deliverable from the edge. These variables can also be used to evaluate conditional 
logic. 
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Kgure 4 illustrates the representative "Handhdds'' container page described 
earlier having individual content fragments that are assigned individual caching 
profiles and behaviors according to the present invention. In particular^ each fragment 
is treated as its own separate object with its own cache entry and corresponding HTTP 
S headers. Generali2dng^ a content fragment is a logical sub-piece of a larger piece of 
content As will be described below, prefierably a content provider can defines rules for 
how an object is served. These rules are provided in the form of object "metadata/ arul 
preferably there is a metadata file per content provider customer* MetadataWy be 
provided in many ways, e.g^ via HTTP response headers, in a configuration file, or a 
10 request itself. The rules for tiie object thus are derived from the metadata for that 
customer. 

According to tiie invention, a given content fragment may have its own 
cacheability and other properties set by way of headers or cdnfiguiation files, or in 
some other manner. Thus, a given container may be cached for several days, while a 

15 particular fragment that contains a stoiy or advertisement may only be cached for 
minutes or hours. Particular fragments may be set so they are not cached at all. The 
container page may be made non-cacheable^ which allows for user-spedfii: data to come 
back to the container page and then be induded/acted-upon in some inclttde(s) that are 
called from the container page. According to the invention, cached templates and 

20 fragments may be shared among^ multiple users. Thus, for a large number of requests, 
preferably the entire page (or most of it) can be assembled using shared components 
and delivered from a given server dose to requesting end users. 

More generally. Figure 5 illustrates a container page 500 from an e-commerce 
Web site that contains: 

25 •A personalized greeting 502 generated by a personalization engine 

• A targeted advertisement 504 generated by an ad serving technology 

« A navigation bar 506 and a footer 508 generated by a content management 
system 

• Several product recommendations 510 generated by a customer relationship 
30 management (CRM) application. 
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As can be seeiv the navigation barS/ liiiks and copyright notice (elements 506, 
508) are static content, the personalized greeting 502 is unique for the customer, the 
targeted ad 504 depends on the user's location (e.g., the user's IP address), and Ihe user 
recommendations 510 are made on the basis of complex analysis by the site's 
5 collaborative filtering engine. Thus, most of the content on this page is personalized 
and dynamically generated. Nevertheless, the page can be successf uDy delivered from 
an edge server using Figure 6 illustrates a representative ESI version of the page. 
In this example, the representative ESI markup, facilitates the coexistence of cacheable 
and imcacheable content on the same page. In particular, blocks (3 and 5) are static, and 

ID blocks (1, 2 and 4) are dynamic. The static Wocks make up tlie template, and dynamic 
blocks are included using various ESI commands. In addition, the ESI markup enables 
page logic and delivery separation. In particular, consider the block (4) 
recommendations. This block is uncacheable and, as a consequence, the request for this 
content is tunneled back to tiie origin server. What is returned, however, is preferably 

15 not the full HTML block, but rather a list of references to the recommended products, as 
shown in Figure 7. In this example, it should be noted that eadi of the product 
descriptions is cacheable, and preferably the total number of products recommended to 
all the users can be easily cached on the edge. The logic to generate the 
recommendations fragment preferably resides at the origin server, but the actual HTML 

20 is cached and delivered from the ed^ server. Also, because requests for non-cacheable 
fragments like recommendations Jitml preferably are tunneled to the origin server (e.g., 
over a persistent connection), they can be used to update session state infoimatian. 
Therefore, user recommendations may be caused to depend on previous pages visited. 
Returning back to the example in Figure 6^ fragments (1) and (2) illustrate how 

25 business logic is mcorporated on a page. In fragment (1), the value of cookie 

"usemame" is substituted into the body of the page to produce a personalized greeting. 
Fragment ^) illustrates personalization and an ESI conditional for which advertisement 
to include, which is dependent on the user's geographic location. If ihe user is from the 
USA, the us^adhtml fragment is included. If the user is from Canada, then 

30 canada_adi\tml is included. Otherwise, a generic ad is shov/n. The CDN can provide 
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information about user's location availabte to the content providers. Of course, 
us_ad.html, canada_ad.htnil, and generic^ad Jitml all can be cached on the network. 

Thus, even ihou^ most of this example Web page is generated dynamicaUy/ tfie 
majority of the fragments making up the page are cached and delivered £rom the edgq. 
3 The amount of data tiiat has to be retrieved from the origin site is very small. Has 
results in a significant performance improvement for the end user and a reduction of 
infrastructure reqtured to deliver the site. 

The dynamic content assembly medianism of die invention is now described in 
more detail. As will be seen, this mechanism generally is in^lemented as software^ Le., 

10 as a set of program instructions^ in commodity hardware running a given operating 
system. In one embodiment, the dynamic content assembly (DCA) mechanism is 
implemented in an Internet content delivery network (ICDN). Typically, a 
conventional CDN is implemented as a combination of a content delivery 
infrastructure, a request-routing mechanism^ and a distribution infrastructure. The 

1 5 content delivery infrastructure usually is comprised of a set of "surrogate" origin 

servers that are located at strategic locations (e.g., Internet network access points, and 
the like) for delivering copies of content to requesting end users. The request-routing 
mechanism allocates servers in the cmtent delivery infrastructure to requesting clients 
in a way diat, for web content delivery, minimizes a given clients response time and, 

20 for streaming media delivery, provides for the highest quality. The distdbution 
infrastructure consists of on-demand or push-based mechanisms that move content 
from the origin server to the surrogates. A CDN service provider (CDNSP) may 
organize sets of surrogate origin servers as a ''region.^ In this type of arrangement; an 
ICDH region typically comprises a set of one or more content servers that share a 

25 common backend^ e.g., a LAN, and that are located at or near an Internet access point 
Thus, for example, a t)'pical ICDN region may be collocated within an Internet Service 
Provider (ISP) Point of Presence (PoP). A representative ICDN content server is a 
Pentium-based caching appliance running an operating system (e.g., Linux, Windows 
NT, Windows 2000) and having suitable RAM and disk storage for ICDN applications 

30 and content delivery network content (e.g., HTTP content, streamir\g media and 

applications). Such content servers are sometimes referred to herein as "edge" servers 
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as they are located at or near tiie so-called outer reach or "edges" of the Internet. The 
ICDN typically also includes network agents that monitor the network as wdl as the 
server loads* These network agents are typically coUocated at third par^ data centers 
and may exist reside in CDN content servers. Map maker software receives data 

5 generated bom ihe netvvork agents and periodically creates maps that dynamically 
associate IP addresses (e.g., the IP addresses of client-side local name servers) with the 
ICDN regions. In one type of service offering, known as Akamai Freeflow, from 
Akamai Technologies, Inc. of Cambridge, Massachusetts, requests for content that has 
been tagged for deliveiy from the ICDN are directed to the "best" region and to an edge 

10 server within the region that is not overloaded and that is likely to host the requested 
content Thxis, the mapping of end users requests to edge servers is done via DNS that 
is dynamically updated based on the maps. While an ICDN of this type is a preferred 
environment the dynamic content assembly mechanism may be incorporated into any 
network, machine, server, platform or content delivery architecture or framework 

15 (whether global, local, public or private). 

Figure 8 illustrates a typical machine configuration for a CDN content edge 
server on which the inventive DCA mechanism is implemented. Typically, die content 
servar 800 is a caching appHance running an operating system kernel 802, a fde system 
cache 804, TCP connection manager 806, and disk storage 808. File system cache 804 

20 and TCP connection manager 806 comprise CDN global host (sometimes referred to as 
^GHost") software 808, wWdv among other things, is used to create and manage a 
"hot" object cache 812 for popular objects being served by tiKe CDN, In operation, the 
cont»t server 800 receives end user requests for content, determines whether the 
requested object is present in die hot object cache or the disk storage, serves the 

25 requested object via HTTP (if it is present) or establishes a connection to another edge 
server or an origin server to attempt to retrieve the requested object upon a cache miss. 

For purposes of illustration only, GHost software 808 includes a dynamic content 
assembly base layer 814> and an application programming interface 816 that enables die 
base layer to instantiate and use one or more of a set of processors SlSa-iL 

30 Generalizing, a "processor^ is any mechanism that algorithmically processes a formal 
language to generate output that differs from the input. Each processor is designed to 
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process a given type of content, and a given container may include ^mixed" content, 
namely, content fragments of varying type. An example would be an HTML page that 
uses an <esianclude> tag for a fragment that needs to be first processed by XSLT, as 
more particularly desaibed below. Thus, in the pluggable architecture illustrated in 
S Figure 8, a given, processor 818 may be a so-called ''ESI" processor for parsing text (such 
as HTML}^ an XML-based. processor (e^g.. Apache Xalan^ Mozilla TransforMiix, IBM 
WebSphere XML4J, or the like) for parsing XML and XSL, a Java-based processor 
including a Java \^tual Machine (p/M^ for processing servlets, .jsp files, and other J2EE 
web applications, a PHP processor for processing PHP, which is a known server-side, 

10 cross-platform, HTML embedded scripting language^ a processor for processing content 
(e.g„ ASP.NET pages) written to confomi to Microsoft's .NET initiative, a processor 
dedicated to processing a given binary file, a processor dedicated to converting a given 
file format to another file format, a processor dedicated to modifying given content in 
some predetermined manner, and other processor(s) as desired to parse/process 

15 content written to conform to other native execution environment(s) and tiiat can 

leverage an imderlying server side scripting language (such as ESI) or other server side 
functionality. 

A particular advantage of the present invention is the ability to handle multiple 
types of content using an integrated pluggable architecture having an und^lying 

20 dyriamic content assembly mechanism. Multiple processors (for processing different 
content types) can be instantiated to handle a specific request for a given container 
page, as will be seen. In particular, preferably a given content request recaved at tiie 
edge server is mapped/ e.g., by content provider-specific metadata, to instantiate a 
given base processor, and one or more additional processors may then be instantiated 

25 as necessary to assemble given content fragments into the container to produce an 
assembled document that is then returned to the requesting end user. Multiple 
processors may also be daisy-chained together to sequentially process a request (e.g., 
ESI-^XSLT->WML). 

Figure 9 is a flowchart illustrating the dynamic content assembly process of the 

30 present invention for an HTML page. In step (1), an end user enters a URL into his or 
her browser, e.g», http:/ /www,cp.com/ index.html . The browser makes a DNS request 
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to resolve www.qj.com and gets sent back an IP address for a given "edge'' server in 
the ICDN. Tliis process is described generally in U.S. Serial No. xx/xxx,yyy, filed April 
17, 2001, titled "HTML Delivery From Edge-Qf-Network Servers In A Content Delivery 
Network/ by Leighton et al., which is incorporated herein by reference. The browser 
5 requests tfie HTML document (e.g.^y.5grzxom) from the identified server. If the 

HTML document (a "container^) is not already cached on the server, the server requests 
the document from the origin server (namely, the content provider), (Or, if the 
document is cached but need to be refreshed^ the edge server sends an If-Modified* 
Since HTTP request to the origin server ox other GHost machine that is known to have 

10 the content). Thecontentprovideroriginserver delivers the HTML page to the CDN 
edge server if necessary (not shown). At step (2), the edge server parses the HTML 
page looking for tags that specify dynamic assembly instructions including, without 
limitation, URLs for HTML chunks to be incorporated in the final HTML page. The 
DCA tags are preferably specified according to ESI, or some other server side scripting 

15 language, as has been described generally eibove. 

Returning to Figure 9, if the additional HTML chunks are not already cached on 
the edge server, tfie server requests the document(s) from tlie origin server. (Likewise, 
if the chunks are cached but need to be refreshed, tiie edge server sends If-Modified- 
Since HTTP tequest(s) to the origui server or another edge server). This is step {3). At 

20 step (4), the origin server delivers the HTML chunk(s) to the edge server. At step (5)^ 
the edge server assembles the final HTML page from the container page and HTML 
chunks/fragments. The final HTML page is then sent to the requesting end user. The 
HTML page may contain URLs or other CDN-modified resource locators to other 
embedded page objects such as .gif, .jpg, or the media-rich content, which is then 

25 requested from the CDN. The CDN delivers this content to complete the HTML page 
delivery process. Even though the page is being dynamically assembled, it may be 
* useful to cache the generated result for some period of time. Thus, for example, if a 
finance page is assembled bom fragments tiiat include the current values of the DJl A, 
NASDAQ, etc., the page can be cached for a given time, e.g., 30 seconds or even a few 

30 minutes. Therefore, if the page gets liit again during that time, it does riot need to be 
reassembled. 
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Figure 10 illustrates tf\e dynamic content assembly process for an XML container 
that requires an XSL transf onnation after the edge server has been selected. At step (1), 
the end user request for the XML container (e.g.^ ./my jcyz-xml) is directed to the 
optimal server for the ttser. The XML object associated with the request may already 
S be cached at the edge server. If die XML source is not cached, it is fetched from the 
origin server and then cached. This is step Q). The edge server then parses through the 
XML page. The XML page typically includes an XSL style sheet At step (3)^ the server 
checks to see if the XSL style sheet is akeady cached. If not, the server fetches the XSL 
object from Its referenced location and, if appropriate, caches it At step (4), the server 
10 transforms the XML per the instructiOTis in the XSL, creating a page that tfie server then 
delivers to the end user. An example of this page is set forth below: 
<?xml version«*1.0"?> 

<?xml-style sheet type="text/xsr href«''identity.xsl''?> 
<!— this is a test document -> 
15 <document> 

<!— test comment -> 
<xname=V>x</x> 
<y name="y''>y</ y> 
<2 name="£">z</z> 
20 </documfint>. 

The above example points out an important advantage of the present in 

invention, hi particular, XSLT allows the content provider to separate data from 

presentation logic v^ effecth^ely. In XSLT, the XML file is often the data that is user- 

spcdfic or uncacheable, and the XSL style sheet is the presentation logic for how to 

25 process the data (which is XML) and gena-ate some output Edge-based assembly 

according to the present invention allows the content provider to do the "presenting" at 
the edge, while still maintaining control over the data and defining the presentation 
logic that the edge server interprets. 

The dynamic content assembly processes illustrated above arc implemented by a 

30 d]mamic content assembly (DCA) mechanism in cooperation with GHost operative in 
an edge server Figure 11 illustrates the basic processing. When tfie GHost software 
1100 initializes, it starts a DCA worker thread 1102, which then loops, looking for work 
that may be pa:f ormed by the mechanism; As described above, it is assumed that 
GHost receives requests for page resources, typically DCA container documents (e.g.. 
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index.hlml, index.)anl, index.jsp, etc.) that may contain ESI-based or other server side 
scripting markup. (XML and JSP pages typically may not have ESI tags in them but 
Still may use other ''include" functionality that permits combining fragments and 
containers). Although not part of the present invention^ the GHost software preferably 
5 includes the abili^ to process a given request according to content provider-specified 
"metadata'' that may be provided to GHost in the request directly, in a request header, 
or via an out-of-band delivery mechanism (e.g,, using the CDN). Thus, a given request 
received by GHost preferably is processed against content provider (CP) metadata to 
detenrune how the request is to be processed by C^ost As an example^ given CP 

10 metadata may simply state that any request ending ivith an .xml extension is processed 
with the XSLT processor. More generally, metadata can be used to control the choice of 
processor, irrespective on content type or filename extension. 

The metadata-processed request is placed in DCA queue 1104. The DCA queue 
and the DCA worker thread correspond generally to the API 816 illustrated in Figure 8. 

15 The DCA worker thread takes the entry off the queue and parses the client request 
headers. The DCA worker thread then parses the response by splitting it into HTTP 
response headers and a request body to fomi a data object, sometimes called a 
BuffexStadc Once tlds processing is done, the DCA worker thread instantiates the 
appropriate processor 1110 based on die metadata for the specific request (which may 

20 be a request for the container or some fragment in the container) . Processor 1110 

parses the body and creates a given representation^ preferably a "parse tree''' o£ the ESI 
code in the document and tfie surrounding body, which is typically HTML. 

Generalizing, processor 1110 parses the data object by scanning the data and 
applying appropriate grammar rules to create a tree representation of the data. By way 

25 of brief background, it is well knovm that HTML is limited because style and logic 

components of an HTML document are hardcoded. XML provides a way for an author 
to create a custom markup language to suit a particular kind of document. In XML, 
each document is an object, and each element of the document is an object The logical 
structure of the document typically is specified in a Document Type Definition (DTD). 

30 A DTD comprises a set of dements and their attributes, as well as a specification of the 
relationship of each element to other elements. Once an element is defined, it may then 
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be associated with a style sheet, a script HTML code or the like. Thus, with XML, an 
author may define his or her own tags and attributes to identify structural elements of a 
document which may then be validated automatically. An XML document's internal 
data structure representation is a Document Object Model (DOM). The DOM makes it 
S possible to address a given XML page element as a programmable object Basically^ it is 
basically a tree of all the nodes in an XML fOe. This is the tree representation described 
above. 

Preferably the tree representation is doned and tfien cached in the ghosf s cache. 
This step is not required but provides certain performance advantages, as will be 

10 described below. The processor then processes or "walks" the tre^ moving from top to 
bottom and left to right. Depending on the ESI markup, tliis processiiig evaluates 
expressions, performs variable substitution, fires include(s), and the like. If there is an 
include tag, the worker thread links the include to its parent (so that the include can be 
resolved to its parent later), forms a request for the include, and places the request on a 

15 GHost queue 1112. Preferably, GHogt includes a worker tliread 1114 that continually 
scans the GHost work queue 1112 for work. The request is then picked up by GHost 
which processes it, f or example, by retrieving the object from cache (disk ox memory) 
or, if necessary, from the origin server (or another GHost machine). Once retrieved, the 
fragment is placed on the DCA queue, and the process as described above basically 

20 starts over* In particular, the response headers are parsed, although the request 
headers do not need to be parsed again because they are the same as in the parent 
document. After the include is processed, the child process notifies the parent mth 
data and, if appropriate, an error code. 

The processor then ''serializes'^ the results generated by processing the content 

25 directives by concatenating the results according to the tree representation. The 
content directives typically are asjTtichronous operations and, as a consequence, the 
results may be generated in an asyndvonous manner. The serialization process may 
concatenate results as those results become available to optimize processing. When 
finally completed, the processor places the BuffexStack back onto the GHost queue 1112, 

30 from where it is retrieved by GHost worker thread 1114. GHost then returns the 
requested page (viz., the container processed according to the dynamic content 
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directives) to the requesting end user to complete the page deliverjr process. The 
processor used to process the request is then extinguished, and the DCA worker thread 
moves on processing other items in the DCA queue. 

As described above, preferably the tree representation is cloned and cached in 
5 the GHost object cache. Caching the parse tree obviates the scanning and parsing 
operations, which may add significant latency to the overall DCA process and that are 
often unnecessary across multiple requests for the same object When the tree 
representation is cached and is appropriate for the then-current resource request, the 
djnnamic content assembly page directives are carried out immediately upon receipt of 

10 the parse tree. 

The following describes how the inventive d3niamic content assembly 
medianism processes an HTML page having a fragment that needs to be processed by 
XSLT. Figure 12 illustrates the overall architecture of a CDN having edge servers that 
support dynamic content assembly of a container document having content fragments. 

1 S This example illustrates how the DCA mechanism provides a pluggable architecture for 
midtiple content types ttiat use ESI directives. Assume ti\at the sample container page 
(fbo.html) has the following markup and that the XML page bar.xml has an associated 
stylesheet: 

20 <htm]> 
<body> 

<esi:indude src-"bar.>cmiy> 

</body> 

</htmI> 

Preferably, the XSLT processor processes ttie XML file before bdng iiu:luded in the 
HTML container page« ^ 

. The overall processing of tfie container is carried out as foUovra. First, a request 
is received at CDN edge server for the f oo Jttml container. It may be assumed that the 
30 request was directed to that server through a CDN request routing mechanism, 

although this is not a requirement Because of customer metadata, GHost software in 
the CDN edge server is directed to process the 'request before responding to the end 
user. To this end, GHost first places the request on the DCA queue, as previously 
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described. The DCA worker thread (which was initialized on startup of GHcst) takes 
tl\e entry q££ the DCA queue. The DCA worker thread parses the request headers (i.e., 
client request headers). It then parses the response by splitting it into HTIP response 
headers and the respective body. Once this processing is done^ the worker thread, 
5 based on metadata, instantiates tiie appropriate processor to process the request bi this 
example, an ESI processor is instantiated to process f oo.html. The ESI processor parses 
the body of the f oo Jitml and creates a parse tree. The processor tiien processes the tree. 
As noted above, this includes evaluating expressions, performing variable substitution 
and, most importantly, firing includes. In this example, there is an XML include, which 

10 is Aen instantiated as a ''child" and processed as follows. 

In particular, the processor links the include to its parent (foo.html) so that the 
parent-rfdld relationship can be maintained in subsequent processing. In a preferred 
embodiment, diis is aclaieved by storing the link as a state object as part of the processor 
handling the request The linking operation ensure that the include is a component of 

15 foo.html and not its own sepeirate request The request manager then forms a request 
for the indude and places diis request on the GHost queue. This request may take tiie 
form of a URL that is sent to GHost Thus, to GHost, this request looks Uke a normal 
end user browser cormection. As described above, the GHost software continually 
reads the GHost queue for work that the DCA mechsuiism requests. When the GHost 

20 worker thread sees the new request, it retrieves &e object, bar.xnil/ either from cache 
(disk or memory) or, if necessary (because the object is not there or has expired) goes 
forward to the origin server (or another GHost machine) to retrieve it Ftef erably, 
GHost tunnels back to the origin server over a persistent TCP connection to retrieve the 
object. A persistent connection obviates the normal dire&-way TCP handshake used to 

25 set up a connection. The connection may also be secure. Once retrieved (either from 
cache or from the origin server)^ GHost puts the fragment back on the DCA queue. 
Upon receipt of this fragment the process starts over for die most part In particular, 
the response headers are parsed (as there is no need to parse the request headers again 
because they are the same as on the container page). The appropriate processor type is 

30 dien instantiated, e.gv based on metadata. For this indude, an XSLT processor is 

created, and this processor is a child of the ESI processor that was created for fooiitml. 
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As noted above, the XML document requires an XSL style sheet. Thus, 
preferably the XML processor parses the XML file first and creates a DOM tree. It then 
fires a request (or the XSL document (the XSL include voll be a child of the XML 
include). As before^ this operation generates a request that is put on the ghost work 
5 queue for retrieval When a response comes bade to DCA, the XSL file is parsed and a 
DOM created for this file. In the final step, both DOM trees QCML and XSL) are sent 
into the XSLT processing engine. The engine performs the transformation and hands 
back a result Onoe the child has completed processing, it notifies its parent (fooJifml) 
that the processing is complete. Upon receiving notificatioiv the parent takes the 

10 resultant data from the fragment (that was generated by the XSLT engine) and inserts it 
into its respective position in tfie container page. In this example, the '<es!:indude 
src="bar.xml"/>' is thus replaced with the result of the XSL transformation. 

Finally, because there are no more child processor(s) outstanding, the parent 
processor (in this case, the ESI processor) serializes its output and places the final 

15 results (the BufferStack, as processed by DCA) on the GHost work queue. As described 
above^ the GHost worker thread retrieves this object from the queue and returns it to 
the end user browser, where it is rendered in the usual manner. This completes the 
processing. 

The following describes representative processing of a servlet or jsp object 
20 FantuliariQr with Java is presumed. The request ^t requires Java processing is first 
mapped, e.g,, by CP-metadata, to the DCA work queue. As described abo ve, the DCA 
worker thread takes the request off the DCA queue and instantiates a processor to 
process the request The processor is a JavaProcessor object. TheJavaProcessor 
forwards this initial user request to an embedded JVM instance that was invoked as 
25 part of system initialization using Java Native Interface (JNI) invocation interfaces. JNI 
allows Java code that runs within a Java Virtual Machine to operate with applications 
and libraries written in other languages^ such as C, C++, and assembly. Preferably, 
communications between the JavaProcessor objects and Java objects in the JVM go 
through an ESI-Java interface that uses the JNI to access Java objects, and to map data 
30 types. Tliis native object reference is passed back on all calls through the ESI-Java 
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int&rface from Java ot^ects to native objects to properly identify the native^- object being 
called 

Continuing vn&t the example, the request is forwarded to a Java object in the 
JVM called a Connector, and it includes a pointer to the JavaPtocessor native object 
5 The Connector Java object manages a pool of objects called Processors, each of which is 
associated with a Java Thread object Each Processor object has a request object, which 
has an associated InputStream object Upon instantiation, the InputSti^am ol^ect makes 
a native call through the ESI-Java intecEaccv passing the nalivc object reference from die 
[avaProcessor native object associated widi the request The implementation of this 

1 0 native call uses this reference to contact the appropriate JavaProcessor object and obtain 
the request data in BufferStack form. A JNI method then converts this data to a Java 
byte array data type, tiius copying this data into the InputStream Java ot^ect 

As processing continues, additional data may be needed {e,g., from GHost) to 
complete Java processing of the initial request This additional data may include Java 

1 5 class files, JSP source files, static HTML files, XML configuration files, or tlie like. 
These requests are sent over the ESI-Java interface using a native method call. The 
implemmtation of this native method makes a call to the JavaProcessor olq'cct for the 
data. The JavaProcessor object creates a child JavaProcessor object axid puts the request 
for this additional data on die GHost work queue. When GHost puts die requested 

20 data back on the DC A queue, a notification is sent to the Java object that requested the 
data. This Java object is notified through the ESI-Java interface using the jNI to call a 
notify method on that Java object; and tiien converting the BufferStack to a Java bjrte 
array. 

From the above examples, which are merely representative, one of ordinary skill 
25 will appreciate lliat the present invention provides a highly-ef ficientr yet generalized 
framework that permits combination of content fragments and containers of a plurality 
of different types in essentially arbitrary ways. The mechanism enables content 
providers to carry out dynamic content assembly, content generation and content 
modification/ all from the network edge. 
30 In particular^ although most of an example page is generated dynamically, the 

majority of the fragments making up the page are and/or can be cached and delivered 
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from the edge server. The amount of data that has to be retrieved from the origin 
server (following assembly and delivery of the page in the first instance) thus is very 
small. This results in a dgnificant pezfonnance improvement for the end user and a 
reduction of infrastructure (viz., hardwarSy software, bandwidth, etc.) required to 
5 deliver the content provider site. In particular^ it is well-known that a typical data 
center environment for a managed Web site comprises a large number of expensive 
components including routers, reverse proxy caches, switdies, local load balancers, 
domain name service (DNS) servers, Web servers, application servers, database servers 
and storage, firewalls, and access lines, bdeed, the typical architecture of a hosted E- 

10 business infrastructure is best depicted in tiers. A content generation tier is typically 
centrally maintained in an enterprise data center or a hosting facility^ Its primary 
function is for application coordirxation and communication to generate the information 
that is to be presented to the end-user based on a set of business rules. It tj'pically 
includes application servers, directory and policy servers, data servers, transaction 

15 servers, storage management systems, and other legacy systems. Between the 

application tier and the content delivery infrastructure is a simple integration layer diat 
pro^des HTTP-based connectivity t^etween die e-business applications of the content 
generationtier and the content delivery tier. In the distributed architecture, this tier 
consists of a single or few Web servers serving as HTTP communication gateways. The 

20 content delivery tier includes those machines such as Web servers and routers that are 
used to deliver the content to the requesting end user. As one of ordinary skill in the 
art^vill appreciate, the dynamic content assembly mechanism of the present invention 
enables a portion of the middle tier and potentially all of the content delivery tier to be 
moved to the CDN. Figure 12 illustrates a data center that has been provisioned to use 

25 the present invention. As can be seen, the content delivery tier, namely, the routers, 
reverse proxy caches, switches, local load balancers, domain name service (DNS) 
servers, Web servers, and the like, are omitted, as they are not necessary for this 
particular content provider. In addition, much of the dyrvamic assembly that is done by 
the application server occurs on the edge servers as well (at least after the page is 

30 assembled for the first time). The cost savings to the content provider in terms of 
facilities, equipment, services, bandwidth, processing, and labor are manifest 
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The present invention enhances the rdiabOity, performance and scalability of 
sites that rely heavily on dynamically generated content and personalization. The 
performance of Web applications that run in a distributed aichitectuie increase 
substantially. The content deliveiy system avoids performance problems introduced 
5 by the Internet by locating and cadung content near the end-users. Also, moving 
dynamic content assembly to the plurality of servers (which may number in the 
thousands) at the edge of the network eliminates the central performance botdeneck of 
the application server's page assembly engines personalizing content for aU users. The 
edge network significantly reduces the load on the originating site by serving static and 

10 dynamic content. Caching frequently requested content at the edge of the network 
decreases bandwidth requirenients at tfie origin site* In particular, the content 
provider no longer needs to maintain a possibly over-provisioned site just for peak 
loads. In addition, the global content delivery network allows liie content provider to 
ext^ that centralized application infrastructure into new locations by offering a 

15 uniform platform for new devices and applications. The CDN enabled with the DCA 
mechanism provides, in effect, unbounded scalability and reliability. 

A CDN that includes the dynamic content assembly mechanism of the present 
invention preferably leverages any convenient server side scripting language or server- 
based functionality to enable the content pro\dder to cache, distribute and assemble 

20 individual content fragments on the edge of the Internet Web sites widi a lot of highly 
dynamic content that may socm non-cacheablc are really simply combinations of 
cacheable content By utilizing the DCA mechanism and an appropriate server-based 
functionality (such as ESI), e-businesses can dynamically assemble personalized and 
dynamic content on the edge of the Internet just as they do in their own data center. 

25 Even serving truly non-cacheable content through the CDN is generally faster 

and more reliable than having customers go direct from their browser to the content 
provider's origin servers. The origiti server preferably maintains persistent connections 
to a finite number of CDN edge servers, rather than tiying to do this with huge 
nimibers (perhaps millions) of individual end user browsers. A persistently- 

30 maintained connection between tiie origin server and the CDN speeds up requests, 
malce the origin server generally more reliable and less variable in performance, and it 
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o£Qoads from the origin servei a significant amount of CPU processing and memory. 
Performance Improven^nts resxxlt from keeping the connection open between the edge 
and the origin ser\rer with data flowing through it^ avoiding the overhead associated 
with setting up a separate connection for every browser request 
5 The integration of ESI into content management systems and application servers 

affords the content provider great flexibility in choosing ^ best deployment model for 
an appIicatioiL Web applications fhat use ESI can be deployed in an intranet 
environment where 4ie content is being assembled on the local application server or it 
can be scaled to a global audience on an extranet or the Internet by simply using an . 

1 0 Internet CDN. Because both the application server and die CDN server understand the 
ESI language and content management protocol, applications can be deployed in a 
flexible and transparent manner, without requiring any changes to the application itself 
and wth the beneEts of reduced complexity and Infrastructure costs. 

Many variants are within the scope of the invention. Thus, for example, the 

1 5 QDN can xise data compression to reduce the amount of traffic between the origin 

server and edge server even more. If the requesting browser supports compression, the 
CDN edge server will send compressed content to the user. In the event that the 
browser does not support compression, die edge server will decompress the content 
and send it to the browser uncompressed. CDN edge servers can also forward or 

20 process most commonly used technologies employed lor personalization, such as User- 
agentS/ cookies and geographic location. 

Although the invention has been described as leveragpLng what has been 
dcscnbed as ESI, this is not a requirement of the invention* Any convenient server side 
scripting language or other server-based functionality may be used to fire ]nclude(s) 

25 identified in a given container or content fragment; to evaluate conditional expressions, 
to perform variable substitutions, and the like Generalizing, the mechanism of the 
present invention may be used with any generalized server-based functionality 
including, without Umitation, ESI, SSI, )GSI, JSP, ASP, PHP, Zope, ASP.NET, Perl, and 
many others. In addition^ while the output content types illustrated above are HTML 

30 and XML, this is not a limitation of the invention either. Other convenient output 
formats include, without limitation, text (other than HTML and XML), -pdf, od\er 
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binaries, .gif files, .jpg files, and the like. Generalizing, any content that includes server- 
based embedded scripting fuiurtionality (e.g., ESI tags) can be processed by the 
inventive mechanism. ESI is desirable as it is a scripting language lluit can be 
embedded in any content irrespective of mime-type, but the invention is not limited to 
5 use with ESI. Further, as noted above, the inventive framework may be used to provide 
dynamic content generation and/or modification, not just content assembly. This 
includes conversion of one file format to another (e.g., HTML to WAP, .gif to .jpg), 
compression, decompression, traiulation, transcoding, and the like. 

Having thus described our invention, what we now claim is set forth below. 

10 
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CLAIMS 

1. A method, operative at a network server, for processing a request for a 
container, wheiein the container comprises markup identifying one or more content 
fragments and the container aiui each content fragment may have a distinct cache 
profile, comprising: 

determining if the container is cached at the server or needs to be refreshed; 
if dxe container is not cached at the server or needs to be refreshed, contacting an 

origin server or another network server to obtain dte containa^ 

instantiating a given processor selected based on a content type of the containers- 
processing the container to identify page assembly instructions and markup for a 

given content fragment; 

determining if tiie given content fragment identified by the maricup is cached at 

the server or needs to be refreshed; and 

if the given content fragment identified by the markup is not cached at the server 

or needs to be refreshed, contacting an origin server or another nfitworI< server to obtain 

die given content fragment; 

assembling the given content fragment into the container according to the page 

assembly instructioxis; and 

delivering &e container having the given content fragment assembled therein as 

a response to tihe request. 

2. The method as described in Qaim 1 the container comprises a first content 
type and ttie given content fragment comprises a second content type. 

3. The method as described in Claim 2 wherein the first content type differs 
from the second content type. 

4. The method as described in Claim 2 wherein the first content type is the 
same as the second content type. 

5. The method as described in Qaim 1 wherein tixe processing step includes: 
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parsing the container to generate a given representation; and 

processing the given representation to identify the page assembly instructions. 

6. The method as described in Qaim 5 wherein the given representation is a 
5 parse tree. 


10 


7. The method as described in Qaim 5 further including the step of caching 
the given representation of ihe container to obviate the step of parsing the container 
upon receipt at the server of a subsequent request for ttie container. 

8. The method as described in Qaim 1 wherein the network server is a 
content server in a content delivery network (CDN)* 


9. The method as described in Qaim 1 wherein the server communicates 
1 5 with the origin server or the other network server over a persls t^t connection. 


10* A mechanism operative on a network server for assembling content 
fragments into a container, wherein the container comprises markup identifying one or 
more content fragments and the container and each content fragment may have a 
20 distinct cach^ability and access profile, comprising: 

a set of one or more processors, wherein a given processor is associated with a 
given content type; 

an application programming interface (API) responsive to a request for the 
container or a given content fragment for (a) parsing markup and generating a 
25 representation of the markup, and (b) for instantiating a given processor to process the 
request depending on the given content type in the markup; 

wherein tlie given processor serializes given data generated during the 
processing of the request according to the representation to generate a response. 


30 11. The mechanism as described in Cairn 10 wherein the processor is an 

HTML processor. 
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11 The mechanism as described in Qaim 10 wherein the processor is an 
XSLT processor. 

S 13. The mechanism as described in Claim 10 wherein the processor is a Java 

processor. 

14. The mechanism as described in Qaim 10 wherein the pro<£ssor is a PHP 
processor. 

10 

15. The mechanism as described in Qaim 10 wherein the network server is a 
content delivery network (CDN) surrogate origin server having an object cache. 

16. The mechanism as described in Qaim 10 wherein one or more processors 
are instantiated by the application programming interface to process a given request, 

15 

17. The mechanism as described in Claim 16 wherein a first processor is a text 
processor ttiat processes the container and a second processor is an )€LT processor that 
pn>c€5ses an XML content fragment 

20 18. The mechanism as described in Claim 10 wherein a first processor is 

instantiated by the application programming interface as a parent processor and/ 
thereafter, a second processor is instantiated by the application programming interface 
as a child processor. 

25 19. The mechanism as described in Claim 10 wherein the given representation 

is a parse tree. 

20. An apparatus operating as a surrogate origin server in a content delivery 
network for receiving end user requests for a container, wherein the container 
comprises markup Identifying one or more content fragments, comprising: 
30 a cache; 
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a set of one or more processors, wherein a given processor is associated with a 
given content type; and 

code responsive to a request for a cont^er (a) for instantiating a base processor 
according to content provider-specific metadata, and (b) for instantiating one or more 
additional ]»ocessors as needed by the base processor to thereby assemble gjiven 
content fragments into the container to produce an assembled document; 

wherein the container and each content £ragment may each have a distinct 
cacheability and/ or refresh profile. 
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<html> 
<body> 

<!— personalized greeting (I) -> 
HeDo $ffnTPJX)OKIE{"o$emame«} 

targeted ad® 
<esi:choose> 

•cesinjAen te5t=^GEO{coimeiy__codc}) = 'US' "> 
<esi:iQcIu(ie src^_adiiliiil^ 

<csi:whcn test=^'SCGEO{couiitiy_code}) = 'Canada' 
<esi:tDc2ade src^^canadajEulhtini^ 

</cs!:whMi> 

<esi:othenvi5c> 

<Bsi:indude src=generic_Bd.htnil/> 

^es!:cboo5e> 

<| — Static navigatiOD bar (3) -> 

<a hrcf"...><a hrcf-...> <a hirf=,.> <a hrt^.„> 

<l— Personalized recommcodatians (4) --> 
<esi:mclude srcRreconunendations Ji&n]/> 

<»— Static links, copytigbt, etc (5) 

<a href=...> <ahrB^...> <5a hrft^...> <a Iupe^.,,> 

Copyright 2001, etc. 

</body> 

</htm> 


Figure 6 


Figure/ 


<esi:include src="products/A.html" /> 
<esi:mclude src- Vroducls/B Jitnil'* /> 
<esi:mclude sic^'products/Citml" /> 
<e5i:include src="products/D.htinr* /> 
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